<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<link rel="Stylesheet" type="text/css" href="doc.css" />
<title>Using OCL</title>
</head>
<body>
<h1><a name="top">Using OCL</a></h1>
<p>
Out of the box, the EMF Validation Framework provides support for two
<a href="languages.html">constraint languages</a>:  Java and OCL.  As we have seen in
<a href="constraints.html">another topic</a>, Java constraints register the name of a
class extending the <em class="CodeName">AbstractModelConstraint</em> class.  For
constraints specified in OCL, there is no code required.
</p><p>
The <em class="CodeName">org.eclipse.emf.validation.ocl</em> feature provides an
<em class="CodeName">OCL</em> language that allows static constraint providers to specify
OCL constraints directly in the OCL.  Moreover, because this OCL capabilitiy is contributed
as a <a href="languages.html">language provider</a>, any dynamic constraint provider
that delegates <a href="dynamicProviders.html#creating">constraint creation</a>
to the <em class="CodeName">AbstractModelConstraintProvider</em> class can also specify
its constraints in OCL by providing
<a href="../javadoc/org/eclipse/emf/validation/service/IConstraintDescriptor.html"><em class="CodeName">IConstraintDescriptor</em></a>s
with OCL as the <em class="Code">language</em> and the expression as the
<em class="CodeName">body</em>.  Indeed, this structure is illustrated in an example
static provider:
</p>
<pre class="Code">
&lt;extension point="org.eclipse.emf.validation.constraintProviders"&gt;
  &lt;category name="Library Constraints" id="com.example.library"&gt;

  &lt;constraintProvider&gt;
    &lt;package namespaceUri="http:///org/eclipse/emf/examples/library/extlibrary.ecore/1.0.0"/&gt;
    &lt;constraints categories="com.example.library"&gt;
      &lt;constraint
            <b>lang</b>="<b>OCL</b>"
            severity="WARNING"
            mode="Live"
            name="Library Must have a Unique Name"
            id="com.example.library.LibraryNameIsUnique"
            statusCode="1"&gt;
        &lt;description&gt;Libraries have unique names.&lt;/description&gt;
        &lt;message&gt;{0} has the same name as another library.&lt;/message&gt;
        &lt;target class="Library"&gt;
            &lt;event name="Set"&gt;
                 &lt;feature name="name"/&gt;
            &lt;/event&gt;
        &lt;/target"&gt;
        <b>
        &lt;![CDATA[
        Library.allInstances()-&gt;forAll(l |
            l &lt;&gt; self implies l.name &lt;&gt; self.name)
        ]]&gt;
        </b>
      &lt;/constraint&gt;
    &lt;/constraints&gt;
  &lt;/constraintProvider&gt;
&lt;/extension&gt;
</pre>
<p>
This looks very much like the Java example of a
<a href="staticProviders.html#declare">static constraint provider</a>, except for the
language specification and the element body content in place of a Java class name.
Here, we use a CDATA section to simplify working with the angle brackets in the OCL
expression.
</p><p>
The OCL language provider supports a <em class="CodeName">{0}</em> parameter in the
message.  It is replaced by the validation target element.
</p><p>
This works well for simple constraints that require only the MDT OCL component's 
Ecore parsing environment, without any customizations such as global variables.  For
applications that have such requirements, the OCL feature provides an
<a href="../javadoc/org/eclipse/emf/validation/ocl/AbstractOCLModelConstraint.html"><em class="CodeName">AbstractOCLModelConstraint</em></a>
class that can be extended by a custom OCL constraint implementation.  See the
<a href="languages.html">Constraint Languages</a> topic for details of how to plug in
alternative factories for constraints, keyed by the <em class="CodeName">language</em>.
</p>

<hr/>
<p>
<a href="https://www.eclipse.org/legal/epl-2.0/">Copyright (c) 2000, 2007 IBM Corporation and others.</a>
</p>
</body>
</html>
